Lazy creation of the Set resolving #3329
Conversation
|
Also for #3317 For this PR, since the field is protected, subclasses can rely on the eager initialization of the field, even if cyclic resolution unlikely to be a common case. I have however only found one case by searching through GitHub (https://github.com/folmate/refinery_class2Relational/blob/1a722b38e59aa07d21aa50eae2f4bcfb99e83709/subprojects/language/src/main/java/tools/refinery/language/resource/ProblemResource.java#L57C79-L57C100). Propose, that if this PR is merged, I create myself a PR for that project that fixes the problem if they would ever update Xtext. |
By doing that, when resources already linked are loaded from storage or when no cyclic resolution takes place, no memory needs to be allocated for the set. Signed-off-by: Rubén Porras Campo <[email protected]>
|
The error on MacOs on QuickDebugSourceInstallingCompilationParticipantTest looks unrelated to my change, is it maybe a flaky test? I would like to rerun the job but I think I do not have the rights to do so. Could someone rerun it? |
Indeed that's unrelated and it's a flaky test. I created a separate PR for that #3331 when it gets merged we can restart the failing job, though I don't think that's a blocker for this PR. |
|
I was not totally sure it was unrelated, so I thought I would rather ask. Thanks for confirming it. |
|
I'm closing and reopening to trigger rebuild against the new main branch |
By doing that, when resources already linked are loaded from storage or when no cyclic resolution takes place, no
memory needs to be allocated for the set.